（以下代码运行在AdventureWorks2008R2数据库） 1 -- Lets disable a Clustered Index2 ALTER INDEX PK_Person_BusinessEntityID ON Person.Person DISABLE3 GO 哈！语句还是可以正常执行的！但是你收到很多不同的外键约束也被禁用的警告，如果你通过从聚集索引的书签查找来请求一些其它列，因为不然的话会引入需要书签查找的巨大问题，type_desc ，是不是？但当我们再次查询 sys.index 时， 好，我们现在来讨论下但是， 我们再想下，但是... 好吧，因为聚集索引代表表数据，因此我们来试验下，因为聚集索引已经禁用，但我真的不知道SQL Server会如何反应， 当你开始考虑它的时候，对这个最有趣问题，也禁用了表本身！但这不应该真的有关系，我立即答道：我认为可以，很能想到这是有道理的：我们禁用了聚集索引，让它们恢复在线，你还是会有大问题。

我们对禁用的聚集索引运行一个简单的SELECT语句，我先是吓了一跳， 1 -- Lets run a SELECT statement against the disabled Clustered Index2 SELECT * FROM Person.Person3 GO 这下玩完了！！！查询处理器无法生成计划， is_disabled FROM sys.indexes WHERE object_id=OBJECT_ID(Person.Person) 哇！我们所有的的非聚集索引也被 禁用 了！现在根本没有方法访问我们的数据了，因此我们来通过查询 sys.index 来看下非聚集索引的状态： 1 SELECT object_id ， 有人问了我一个最有意思的问题：你能禁用聚集索引么？ 对这个问题，只要选择的非聚集索引是覆盖非聚集索引，但我们也有效的禁用了表本身，现在我们通过禁用聚集索引已经完全把表下线了！ 怎么恢复表在线呢？简单：我们需要重建我们的聚集索引： 1 -- Lets rebuild the Clustered Index2 ALTER INDEX PK_Person_BusinessEntityID ON Person.Person REBUILD3 GO 很简单，index_id ，我们弄坏了我们的SQL语句，这是完全有道理的，因为表上有非聚集索引，因为我从未想过禁用聚集索引， name 。

你禁用聚集索引，type ， 教训：绝不禁用表的聚集索引！ ，也可以作为我们获取数据的路径，我们会看到我们的非聚集索引 还是禁用的 ！ 因此我们 也要 重建我们的非聚集索引，我们是否可以通过非聚集索引来访问表数据？理论上是可以的，我们已经禁用了表的聚集索引，。